stsd: add roundtrip support for unknown codec - #236

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

what is the intent?

merging a fragmented mp4.

as long as the codec has no strange behavior it should be possible to merge samples from multiple moof+mdat into a single moov+mdat without understanding the full details of stsd

what is the intent?

merging a fragmented mp4.

For what purpose?

as long as the codec has no strange behavior it should be possible to merge samples from multiple moof+mdat into a single moov+mdat without understanding the full details of stsd

There are a bunch of strange behaviours in the codecs we don't support, like layer enhancements, scaling, image sequences etc. I think this behaviour is dangerous. I might be able to live with it behind a feature flag, but would prefer to see the specific codecs implemented if you need them.

merging a fragmented mp4.

For what purpose?

allow playback in players which don't support fragmented files (check out windows)

but if you don't like that point, take an even more simple use case: parse a MP4 file, add/edit some meta atoms and write it again. in that case the actual codec should not matter

There are a bunch of strange behaviours in the codecs we don't support, like layer enhancements, scaling, image sequences etc. I think this behaviour is dangerous. I might be able to live with it behind a feature flag, but would prefer to see the specific codecs implemented if you need them.

i'd more prefer some kind of runtime flag. using feature flags in bigger project can lead to problems if they change behavior. some other crate in a workspace can enable a feature and then it's enabled for all crates (see also #105)

i'd more prefer some kind of runtime flag. using feature flags in bigger project can lead to problems if they change behavior. some other crate in a workspace can enable a feature and then it's enabled for all crates (see also #105)

How would you see that flag working? It would either need to be global state (which has the same problem as feature flags, but less predictability), or some kind of context that gets handed around. Not a big fan of either of those either.

How would you see that flag working?

The only "clean" way I see is an additional parameter to all the decode and encode parameter as Sebastian wrote in #105. I'm also no big fan of this either, since it adds a relevant amount of clutter to those functions, but I don't see any other way to do this, if the library should support different "modes". A generic parameter (Any::decode::<Strict>() vs Any::decode::<Compatible>()) would be even worse to implement.